home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 4 / ETO Development Tools 4.iso / Essentials / MacApp Documentation / MacApp.TECH$ Archives / 1991 / Jan 91 / MacApp.Tech$ 1⁄25⁄91 / 2799-Re Operator overload-Jan91 < prev    next >
Encoding:
Text File  |  1991-03-06  |  4.4 KB  |  102 lines  |  [TEXT/GEOL]
  1. Item    5083185                         25-Jan-91        09:09PST
  2.  
  3. From:   DEREK                           White, Derek
  4.  
  5. To:     GER.XDV0002                     Germany - P1 Ges f Informatik,IVR
  6.         MACAPP.TECH$                    MacApp Technical
  7.  
  8. ------------------------------------------------------------------------------
  9.  
  10. Sub:    re-Operator overloading & C++
  11.  
  12. Dear Eric,
  13.  
  14. We will probably always disagree about this, but here it goes.
  15.  
  16. >...C++ allows you to precisely and succintly define the content of an
  17. >algorithm or idea in a way that is instantly recognizable to the reader.
  18.  
  19. This is true iff the semantics of the overloaded operator roughly match the
  20. semantics of the built-in operator.
  21.  
  22. ------- Some arguments against general operator overloading ------------
  23.  
  24. • Most operators don't have unambiguous definitions for most objects.
  25.  
  26. The only general operators that I can come up with are assignment (:=),
  27. comparison (=, <>), and perhaps relational comparison (<, <=, >, >=).  These
  28. can be overridden in ways much simpler than adding operator overloading to a
  29. language (why should I have to overload SIX comparison OPERATORS when I really
  30. am trying to overload the relational comparison OPERATION?)
  31.  
  32. The + operator probably comes up as the next most general operator.  It can be
  33. used for various scaler, complex, and matrix math, string concatenation, and
  34. set unions of all types.  But what does + mean for a TView?  Add them in a
  35. list?  Take the union of their visRegions?  Return the combined sizes of the
  36. TViews?
  37.  
  38. What about *?  This is even less useful.  Consider your matrix example:
  39.     matrix1 = matrix2 + matrix3*matrix4;
  40. Should the * operator stand for the dot product or the cross product?  It's
  41. ambiguous by looking at the source.
  42.  
  43. The remaining operators tend to be ridiculous when applied to objects, and the
  44. language 'feature' only encourages silly programming.  The best example of this
  45. is AT&T's use of the bit shifting operators (<<, >>) to do object I/O!  The
  46. only apparent reason to use those operators is that they weren't used (yet) and
  47. they looked nice.
  48.  
  49. • Hiding complexity is not always a good idea.
  50. Hiding the call of a 100,000 x 100,000 element matrix multiply behind an
  51. innocuous * can lead you to ignore efficiency considerations.  If I'm going to
  52. something THAT expensive, I want to know about it.  That's just me.  You
  53. probably don't, but you've already got your language :-)
  54.  
  55. >Does the possibility of obfuscation exist?  Yes.  But that is the nature of
  56. >most powerful tools, they are double edged swords.  Quantum mechanics opened
  57. >the door to modern electronics and the atom bomb.  One is a cornerstone of
  58. >western civilization and the other is the shadow of doom.  Does that mean
  59. >quantum mechanics is dangerous?  No.
  60.  
  61. If you want to claim that operator overloading is akin to quantum mechanics
  62. then I think you're hurting your own argument :-)
  63. [Wild claim coming...]
  64. I think there are more people that REALLY understand Quantum mechanics than do
  65. C++, which will have to change if the state of software engineering is not to
  66. get bogged down for the next 5-10 years.
  67.  
  68. I've managed to write code dealing with complex numbers and matrices using
  69. Pascal's normal notation and lived to tell the tale.  Sure, it would have been
  70. cute to overload a couple of operators, but that's not enough reason to add an
  71. entire language feature that's useless or actually harmful in most instances.
  72. Most programming doesn't revolve around matrices.
  73.  
  74. ------- More Random C++ Flames ------------
  75.  
  76. >What C++ demands of the programmer is a strict design philosophy and adherance
  77. >to the karma, if you will, of programming.
  78.  
  79. Actually, C++ demands nothing. But the need to write WORKING C++ programs
  80. demands a lot of discipline.  C++ does little to help you with it though.
  81.  
  82. >The real danger of “bad code” is a fear of the “untrained hacker” entering
  83. >the code arena.  I assume you are not such a person, and that you would do
  84. >well.
  85.  
  86. Everyone was an “untrained hacker” at some point.  Much new software is written
  87. by these people (co-ops, summer students, new hires), because the “old hands”
  88. are bogged down maintaining old code and can't be pulled away to write the new
  89. stuff.  It scares me that these eager young programmers will be seduced by
  90. C++'s features and write REALLY BAD code until they learn ALL the discipline
  91. necessary.
  92.  
  93.  
  94. Hoping to offer an alternative to C++,
  95. and something that new O-O programmers can cut their teeth on (besides broken
  96. glass),
  97. I remain,
  98. Yours,
  99.  
  100. Derek White
  101.  
  102.